每個複雜的問題，都有個簡單的解法。這句話簡直錯得離譜。

Umberto Eco

此文討論Array為主，但可能會牽扯些許Object。

今天老闆不在，就來聊聊一些跟FP無關（但細究其實還是有關）的array雷區吧！人好像也是這樣，每當掙脫了束縛，但身上卻忘不了束縛的影子，甚至渴望重新被束縛。

正如第一天所說的，以下這些雷區，永遠只是偏好，偏好是絕對的情境依賴。

雷區ㄧ：擴充Buit-in

如果你想實作自己的array相關的utility，例如加總sum，很有可能會對array本身prototype進行擴充：

// 可能會被討厭的寫法
// Custom sum function
Array.prototype.sum = function () {
    return this.reduce((acc, el) => acc + el);
}

const lst = [1, 2, 3, 4, 5];
const lstSum = lst.sum();

console.log(lstSum) // 15

一個好的原則是，不要修改或擴充原生buit-in原型，以追求整潔、好維護的程式，並避免不小心的修改。或許有人會說，只要有撰寫符合規格的測試程式，擴充原生原型是被接受的。即便如此，也無法確定與另一支第三方亦擴充原生原型的utility是否會產生有交互作用。故而，建議修改如下：

// 比較不被討厭的寫法
class MyArrayUtils {
    // Custom sum function
    static sum(lst) {
        return lst.reduce((acc, el) => acc + el);
    }
}

const lst = [1, 2, 3, 4, 5];
const lstSum = MyArrayUtils.sum(lst);

console.log(lstSum) // 15

這種寫法不僅避免上述問題，你也可以把你的utility class分享在NPM上供其他人使用。

思考一下，在FP的框架下，上述OOP的class我們應該如何看待？我們將在接下來的日子裡探討類似的問題。

未完待續，持續補充...